Three real bugs surfaced when tipsyhive synced its Makefile to v1.11.0.
All small, all related to Ruby/yq path issues.

Issue #41 — Makefile yq invocation: LANGUAGES read via
`yq '.languages[]'` without `-r`. yq v3 (kislyuk's Python wrapper,
shipped as `yq` on Debian/Ubuntu) returns JSON-quoted scalars by
default; HAS_RUBY filter then matches against `"ruby"` and finds
nothing, so RUBY_DOCKER_ENV doesn't apply BUNDLE_APP_CONFIG and bundler
fails to find project gems. Add `-r` — works in yq v3 and v4 alike.

Issue #43 — `rubocop --check`: the _format recipe passed `--check` to
rubocop. Not a valid rubocop flag. Every Rails project with rubocop in
its Gemfile saw _format fail with "invalid option: --check". Default
rubocop behaviour is already "report, don't autocorrect"; just drop
the flag. `--fail-level error` still gates the exit code.

Issue #42 — Container BUNDLE_PATH envvar: the Dockerfile exported
BUNDLE_PATH=/usr/local/bundle at runtime. Per Bundler precedence
(envvar beats project .bundle/config), consumer projects with
`BUNDLE_PATH: vendor/bundle` had it silently overridden — so
`bundle exec` for project-pinned gems hit Bundler::GemNotFound. Drop
the envvar from the Dockerfile. Bundler now respects the project's
`.bundle/config`. GEM_HOME + PATH at `/usr/local/bundle/bin` keep the
container's own bundled tools (rubocop, reek, rspec, etc.) reachable
via direct invocation.

Validation:
- bash tests/smoke-rails.sh — 4/4 (lint scoping, bundle install,
  .bundle/config override, rubocop --check fix implicitly)
- make check on dev-toolchain itself — pass
- `bundle config` inside container — BUNDLE_PATH no longer shown
- Direct `rubocop --version`, `reek --version`, `brakeman --version`
  all resolve from /usr/local/bundle

Filed by matthew-on-git from a downstream tipsyhive sync.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>